Kernel learning by v1docq · Pull Request #225 · aimclub/Fedot.Industrial

v1docq · 2026-06-02T14:22:22Z

Коммит развивает трек Kernel Learning / Kernel Ensemble и переводит текущий модуль от MVP-каркаса к более строгой архитектуре:

typed domain contracts
pure-core правила для матриц и выбора весов
новые генераторы признаков
forecasting estimator
cache/report слой
расширенная интеграция с FEDOT warm-start.

PR-001: Harden Kernel Contracts And Matrix Semantics

Изменены:

fedot_ind/core/kernel_learning/contracts.py
fedot_ind/core/kernel_learning/kernels/builder.py
fedot_ind/core/kernel_learning/init.py

Что сделано:

В contracts.py добавлены KernelTaskType, KernelNormalization, PSDCorrectionPolicy и KernelMatrixPolicy.
Для FeatureBundle, KernelBundle и KernelSelectionReport добавлены to_dict(), чтобы diagnostics и reports можно было стабильно сохранять в JSON artifacts.
KernelMatrixBuilder теперь явно валидирует train/test feature matrix, train kernel и cross-kernel shapes.
Добавлен guard против ситуации, когда distance matrix ошибочно используется как kernel matrix.
Diagnostics builder теперь содержат JSON-friendly policy payload.

Содержательное влияние:

Kernel Learning получает явный train/test kernel contract.
Ошибка “расстояние вместо ядра” теперь ловится на уровне builder.
Kernel diagnostics можно безопасно писать в benchmark artifacts.

PR-002: Replace Heuristic Selector With Sparse Adaptive MKL Objective

Изменены:

fedot_ind/core/kernel_learning/selection/sparse_mkl.py
fedot_ind/core/kernel_learning/selection/init.py

Что сделано:

Добавлены MKLObjectiveConfig и MKLOptimizationResult.
SparseMKLSelector расширен projected-gradient оптимизацией весов на simplex.
Старый score-based режим сохранён как fallback через optimizer="score".
В KernelSelectionReport.diagnostics теперь сохраняются optimizer, iterations, converged, objective_history и zeroed_generators.

Содержательное влияние:

Выбор kernel weights стал не просто нормировкой эвристических score, а настоящей оптимизацией sparse MKL objective.
Можно сравнивать heuristic baseline и adaptive MKL в benchmark.

PR-003: Stabilize Classifier/Regressor And FEDOT Warm Start

Изменены:

fedot_ind/core/kernel_learning/estimators/base.py
fedot_ind/core/kernel_learning/estimators/classifier.py
fedot_ind/core/kernel_learning/estimators/regressor.py
fedot_ind/api/utils/industrial_strategy.py

Что сделано:

KernelEnsembleBase принимает selector_optimizer, selector_max_iter, selector_tol, selector_step_size.
Classifier/regressor получили совместимые параметры kernel_approximation и nystrom_components.
После fit сохраняется fit_diagnostics_ с kernel bundle summaries, selected generators и selector diagnostics.
IndustrialStrategy теперь выбирает estimator по task type через estimator_by_problem.

Содержательное влияние:

Classifier/regressor не сломаны, но теперь могут использовать новый MKL optimizer и Nystrom approximation.
FEDOT warm-start получает больше диагностической информации для аудита выбранных генераторов.

PR-004: Topological Kernel Generator Under Budget Control

Изменены:

fedot_ind/core/kernel_learning/generators/adapters.py
fedot_ind/core/kernel_learning/generators/init.py

Что сделано:

Добавлен GeneratorBudgetPolicy.
Добавлен BudgetedRepositoryFeatureGeneratorAdapter.
topological_extractor зарегистрирован как budgeted generator с fallback_generator="identity".
Diagnostics фиксируют budget, skip_reason и fallback path.

Содержательное влияние:

Topology можно подключать без риска уронить запуск из-за тяжёлой операции или недоступной зависимости.
Если topology недоступен или превышает budget, pipeline продолжает работать и сообщает причину.

PR-005: Shapelet And Local Pattern Kernel Generators

Изменены:

fedot_ind/core/kernel_learning/generators/adapters.py
fedot_ind/core/kernel_learning/generators/init.py

Что сделано:

Добавлен ShapeletFeatureGenerator.
Зарегистрированы shapelet_extractor и local_pattern_extractor.
Shapelet distances возвращаются как feature representation, а не как kernel matrix.

Содержательное влияние:

Соблюдается архитектурное правило: distance features сначала превращаются в признаки, затем KernelMatrixBuilder строит валидное ядро.
Kernel ensemble теперь может выбирать motif/local-pattern similarity как один из источников.

PR-006: Embedding And Foundation Feature Kernel Adapters

Изменены:

fedot_ind/core/kernel_learning/generators/adapters.py
fedot_ind/core/kernel_learning/generators/init.py

Что сделано:

Добавлен RandomProjectionEmbeddingFeatureGenerator.
Зарегистрированы embedding_extractor и foundation_embedding.
Реализация deterministic, CPU-safe и без внешних model downloads.

Содержательное влияние:

Появился lightweight stand-in для deep/foundation embeddings.
Benchmark может сравнивать classical generators против embedding-like representation без тяжёлой зависимости.

PR-007: Forecasting Target Kernels And OKHS Adapter

Изменены:

fedot_ind/core/kernel_learning/selection/targets.py
fedot_ind/core/kernel_learning/selection/init.py
fedot_ind/core/kernel_learning/estimators/forecasting.py

Что сделано:

Добавлен ForecastTargetSpec.
TargetKernelBuilder теперь поддерживает forecasting и ts_forecasting.
Добавлены horizon-aware target kernels и forecastability_prior.
Добавлен OKHSForecastHeadAdapter как OKHS-compatible precomputed-kernel head.

Содержательное влияние:

Forecasting больше не маскируется под обычную regression target kernel.
Можно строить alignment относительно multi-horizon target structure.

PR-008: KernelEnsembleForecaster Public Estimator

Изменены:

fedot_ind/core/kernel_learning/estimators/forecasting.py
fedot_ind/core/kernel_learning/estimators/init.py
fedot_ind/core/kernel_learning/init.py
fedot_ind/api/utils/industrial_strategy.py
fedot_ind/core/kernel_learning/integration/initial_population_builder.py

Что сделано:

Добавлен публичный KernelEnsembleForecaster.
Поддержаны single-horizon и multi-horizon targets.
Добавлена поддержка head_type="kernel_ridge" и OKHS-compatible head modes.
KernelInitialPopulationBuilder теперь принимает forecasting и ts_forecasting.
Для forecasting warm-start default head теперь ridge, а не treg.
IndustrialStrategy route расширен на forecasting.

Содержательное влияние:

Kernel Learning теперь покрывает три task-семейства: classification, regression, forecasting.
FEDOT warm-start может строить initial assumptions для forecasting отдельно от regression.

PR-009: Cache, Approximation, Reports, Benchmarks, Legacy Cleanup

Добавлены:

fedot_ind/core/kernel_learning/cache.py
fedot_ind/core/kernel_learning/kernels/approximation.py
fedot_ind/core/kernel_learning/reports.py

Изменены:

fedot_ind/core/kernel_learning/kernels/builder.py
fedot_ind/core/kernel_learning/kernels/init.py
fedot_ind/core/kernel_learning/init.py

Что сделано:

Добавлены KernelCachePolicy, KernelCacheKey, InMemoryKernelCache.
Добавлены fingerprint_array и fingerprint_mapping.
Добавлены NystromApproximationPolicy и NystromKernelApproximator.
KernelMatrixBuilder получил optional approximation="nystrom".
Добавлены KernelLearningReport, build_kernel_learning_report и TEXT2IMAGE_PROMPTS.

Содержательное влияние:

Kernel Learning получил основу для cache/budget/approximation experiments.
Nystrom можно включать как controlled approximation policy.
Reports теперь могут включать selection, importance, kernel bundles и prompts для визуализации математической идеи PR.

Tests

Добавлены:

tests/unit/core/kernel_learning/test_cache.py
tests/unit/core/kernel_learning/test_contracts_reports.py

Изменены:

tests/unit/core/kernel_learning/test_kernel_matrix_builder.py
tests/unit/core/kernel_learning/test_selection.py
tests/unit/core/kernel_learning/test_generators.py
tests/unit/core/kernel_learning/test_estimators.py
tests/unit/core/kernel_learning/test_initial_population_builder.py

Проверено:

tests/unit/core/kernel_learning -q: 46 passed
tests/unit/api/utils/test_kernel_warm_start_strategy.py -q: 3 passed

Тесты запускались через локальное окружение venv_3.9_new с PYTEST_DISABLE_PLUGIN_AUTOLOAD=1,

…xt PR

… forecasting estimator, and benchmark diagnostics

…rk modules and group experiments

v1docq · 2026-07-14T12:39:35Z

Обзор KL-изменений перед вливанием в `main`

Область	Оценка	Почему
Постановка задачи, цели и ограничения	8/10	У серии KL понятные цели - убрать старую структуру бенчмарков, ввести типизированный запуск, открыть модели Kernel Learning и сделать примеры воспроизводимыми.
Риски	6/10	Риски бенчмарков и артефактов частично закрыты статусами запусков, журналами ошибок и политикой архивов.
Предыдущие решения и сравнения	9/10	В витрине сравниваются текущий Industrial, старый Industrial, SoTA-результаты, простые базовые модели и варианты Kernel Learning. Для прогнозирования пока нет полноценного SoTA-источника в основной витрине.
Метрики и измерение качества	8/10	Метрики задач и направление оптимизации явно заданы в типизированных конфигурациях и манифестах результатов. Доверительные интервалы, разброс и пороги приемки пока не стали частью контракта.
Данные, разметка и признаки	7/10	Корни данных, манифесты, наборы генераторов и каталоги артефактов видимы. Ссылки на внешнее хранилище пока частично заглушены, а часть локальных сценариев не имеет опубликованного пути получения данных.
Проверка качества и утечки данных	6.5/10	Публичные разбиения бенчмарков и типизированные адаптеры данных снижают риск ошибок. Для пользовательских и локальных наборов данных нужен явный чек-лист против утечек между обучением и проверкой.
Разбор ошибок	B	В пакетах результатов появились покрытие, приросты/просадки, средние ранги, лучших k, диагностика, частоты генераторов, изменение параметров и история эволюции. Разбор доменных ошибок пока неоднороден.
Обучение и воспроизводимость	B+	Типизированные конфигурации, JSON-настройки, возобновляемые артефакты, зарегистрированные запуски и точечные тесты сильно лучше разрозненных скриптов. Полный перезапуск ноутбуков все еще зависит от локальных данных и окружения.
Интеграция и выпуск	5.5/10	Публичные адаптеры бенчмарков, теплый старт для FedotIndustrial и слой инструментов для внешних агентов уже есть. Промышленный выпуск, требования к задержкам и план раскатки не входят в этот PR.
Сопровождение и владение	6/10	Инструкции по запуску и команды проверки есть, но нет легкой таблицы владельцев, правила обновления результатов и цикла контроля свежести бенчмарков и примеров.

Главное исправление перед вливанием - сделать отдельный проход по документации. Надо перенаправить или архивировать материалы про benchmark.v2, обновить старые быстрые инструкции и заполнить реальные ссылки на внешние данные или DVC-хранилище. Рефакторинг бенчмарков вызывает доверие тогда, когда код,
метрики, результаты запусков и примеры смотрят в один и тот же типизированный контракт. После KL-серии этот контракт появился, но его нужно поддерживать в документации и данных.

Резюме

Серия KL переводит IndustrialTS из состояния «много полезных, но разрозненных
скриптов и локальных артефактов» в более явную ML-систему:

benchmark.industrial стал основным исполняемым слоем для бенчмарков.
fedot_ind.core.kernel_learning стал публичной подсистемой Kernel Learning:
в нем есть модули оценки, ядра, генераторы признаков, sparse MKL, кеш,
отчеты и интеграция с теплым стартом.
Эксперименты по бенчмаркам теперь задаются через типизированные сущности:
BenchmarkSuiteConfig, DatasetSpec, ModelSpec, RunSpec, ArtifactSpec.
Анализ результатов вынесен из ноутбуков и ручной обработки CSV в общие
модули агрегации и визуализации.
В папке examples появились понятные роли: утилиты текущего API,
прикладные сценарии, инструменты для внешних агентов и единая папка для
артефактов.
Исторические результаты больше не выглядят как исполняемый код. Они
индексируются как справочные данные через манифесты и витрины результатов.

Это крупное архитектурное улучшение. Что надо доделать - навигацию для нового разработчика: в репозитории все еще есть старые материалы про benchmark.v2, ссылки на внешние данные частично остаются
заглушками, а новая поверхность API достаточно широка, чтобы устаревшая
документация могла сбить с толку.

Что было проверено

Код и документация:

docs/dev_guide/benchmark_infrastructure.md:9 задает benchmark.industrial
как основной исполняемый пакет бенчмарков.
docs/dev_guide/benchmark_infrastructure.md:44 описывает контракт
типизированных конфигураций.
docs/dev_guide/benchmark_infrastructure.md:124 описывает ответственность
за хранение результатов.
docs/dev_guide/benchmark_infrastructure.md:201 описывает правила агрегации
и визуализации.
docs/dev_guide/benchmark_infrastructure.md:315 перечисляет, чего не стоит
делать в новых изменениях.
docs/dev_guide/kernel_learning_benchmark_runbook.md:31 задает правила
конфигурации запусков Kernel Learning.
docs/dev_guide/kernel_learning_benchmark_runbook.md:63 и
docs/dev_guide/kernel_learning_benchmark_runbook.md:108 описывают первый и
второй этап Kernel Learning.
examples/README.md:7 описывает текущее назначение подпапок в examples.
examples/tools_example/README.md:15 описывает каталог инструментов для MCP
и внешних агентов.
examples/artifacts/README.md:8 описывает общий центр артефактов.
benchmark/results/showcase/README.md:14 описывает публичные направления
бенчмарков.

Сводка изменений относительно origin/main:

изменено 789 файлов;
добавлено 104 638 строк;
удалено 198 171 строка;
большой объем удалений связан в основном с очисткой старых примеров,
локальных фикстур данных, benchmarking_utils, benchmark/v2 и устаревших
ноутбуков.

Цепочка связанных issues:

начальные коммиты с реализацией Kernel Learning;
KL-101: реорганизация модуля бенчмарков;
KL-102: единые типизированные конфигурации запусков;
KL-103: переработка примеров, прикладных сценариев и центра артефактов;
KL-104: витрина результатов бенчмарков;
KL-105: инфраструктурные контракты бенчмарков;
KL-106: единый слой агрегации результатов;
KL-201: упрощение и типизация контрактов Kernel Learning;
KL-202: контракт генераторов признаков и крайние случаи;
KL-301: кеш, диагностика и обработка ошибок второго этапа;
KL-302: настройки запусков по умолчанию и удобство пользовательских данных;
KL-401: разделение адаптеров генераторов по тематическим модулям.

Было и стало

Область	Было	Стало
Исполняемый слой бенчмарков	Одновременно существовали `benchmark/v2`, корневые скрипты бенчмарков и `benchmarking_utils`. Было трудно понять, какой путь считать основным.	`benchmark.industrial` стал основным пакетом. Старые обертки, где они еще нужны, живут в `benchmark.industrial.legacy`; исполняемый `benchmark.v2` удален.
Точки запуска экспериментов	Скрипты были разбросаны и часто смешивали константы, описания моделей, сохранение результатов и сам запуск.	Эксперименты сгруппированы по типу задач в `benchmark/experiments/kernel_learning/{classification,regression,forecasting,analysis}` и используют типизированные конфигурации.
Настройки по умолчанию	Списки моделей, метрики, наборы данных и шаблоны выходных папок часто были зашиты в Python-файлы.	Настройки вынесены в JSON, например `benchmark/experiments/kernel_learning/defaults.json` и `benchmark/industrial/experiments/preset_defaults.json`.
Агрегация результатов	Ноутбуки и отдельная CSV-логика каждый раз заново собирали сравнения.	`benchmark.industrial.evaluation.aggregation` и `result_analysis` дают общий путь чтения, проверки покрытия, ранжирования, подсчета приростов, диагностики и сборки отчетов.
Витрина результатов	`benchmark/results` смешивал архивы, SoTA-таблицы, текущие результаты и локальные артефакты.	`benchmark/results/showcase` дает манифестную витрину текущего Industrial, старого Industrial и SoTA-таблиц.
Примеры	`automl_example`, `benchmark_v2`, `data`, `outdated_examples`, `rkhs_okhs` и `real_world_examples` пересекались по назначению.	`examples/utils`, `examples/tools_example`, `examples/real_world_examples` и `examples/artifacts` получили явные роли.
Kernel Learning	Направление уже развивалось, но уровень публичного API был менее явным.	`fedot_ind.core.kernel_learning` открывает оцениватели, контракты, ядра, генераторы, методы выбора, отчеты, кеш и интеграцию с теплым стартом.
Двухэтапная эволюция	Артефакты первого и второго этапа, а также состояния ошибок было трудно переиспользовать.	Первый и второй этап имеют API-классы экспериментов, загружаемые артефакты, диагностику, статусы пропуска/ошибок и ленивые предположения `PipelineBuilder`.
Инструменты для агентов	Примеры в основном были скриптами или ноутбуками.	`examples/tools_example` дает сервисный слой с JSON-запросами и ответами для загрузки данных, обучения, эволюции, PDL и детекции аномалий.
Правила разработки	Архитектурные правила жили в обсуждениях и ревью.	FEDOT-навыки и документация бенчмарков фиксируют локальность реализаций, типизированные конфигурации, вынесение констант в JSON, инвариантные тесты и короткие публичные индексы.

Что изменилось в работе фреймворка

1. Запуск бенчмарков стал типизированным и привязанным к реестру

Новые запуски должны сводиться к схеме:

typed_config.build_suite_config() -> run_registered_suite(...)

Это важно, потому что BenchmarkSuiteConfig теперь несет тип задачи, наборы
данных, модели, метрики, параметры запуска и правила сохранения артефактов как
один проверяемый объект. Разработчику больше не нужно искать константы по
нескольким скриптам, чтобы понять, что именно будет запущено.

Ключевые файлы:

benchmark/industrial/core.py
benchmark/industrial/experiments/registry.py
benchmark/industrial/experiments/manifests.py
benchmark/industrial/experiments/presets.py
benchmark/experiments/kernel_learning/configs.py
benchmark/experiments/kernel_learning/defaults.json

Практический эффект для разработчика:

использовать ModelSpec и DatasetSpec вместо ручных словарей параметров;
добавлять новые наборы настроек через JSON рядом с тематическим модулем;
использовать манифесты для воспроизводимых запусков;
запускать сохранение через run_registered_suite или
run_registered_manifest_path.

2. Стало ясно, где живет код бенчмарков

benchmark.industrial теперь единственный правильный исполняемый пакет для
нового кода бенчмарков. Старый пакет benchmarking_utils удален, а benchmark/v2
перенесен и переработан в benchmark/industrial.

Публичный пакет использует ленивые экспорты: легкие импорты вроде ModelSpec
не должны сразу подтягивать необязательные зависимости для прогнозирования или
глубокого обучения.

Ключевые файлы:

benchmark/industrial/__init__.py
benchmark/industrial/classification.py
benchmark/industrial/regression.py
benchmark/industrial/forecasting.py
benchmark/industrial/datasets/local_io.py
benchmark/industrial/legacy/*

Практический эффект для разработчика:

новый исполняемый код должен жить в тематическом подпакете
benchmark.industrial;
__init__.py должен оставаться коротким публичным указателем;
старые корневые классы бенчмарков допустимы только как совместимые обертки;
исторические пути v2_kernel_learning являются источниками данных, а не
импортируемыми модулями.

3. Результаты запусков стали полноценными входными данными анализа

Запуски теперь сохраняют достаточно информации, чтобы пересобрать таблицы без
повторного обучения:

records/
  runs.jsonl
  metrics.jsonl
  predictions.jsonl
  kernel_diagnostics.jsonl
  kernel_selection.jsonl
aggregate/
  runs.csv
  metrics.csv
  predictions.csv
  leaderboard.csv
  run_metadata.json
  summary.md
resolved_config.json
resolved_manifest.json
run_summary.json
artifact_manifest.json

Это важное изменение для всей системы: анализ результатов больше не привязан к
состоянию ноутбука или локальному Python-объекту.

Ключевые файлы:

benchmark/industrial/experiments/artifacts.py
benchmark/industrial/evaluation/aggregation.py
benchmark/industrial/evaluation/result_analysis.py
benchmark/industrial/visualization/benchmark_results.py
benchmark/industrial/visualization/forecast_comparison.py

Практический эффект для разработчика:

ошибки и пропущенные запуски остаются видимыми в записях;
основные сравнительные таблицы используют успешные строки метрик, если отчет
явно не посвящен ошибкам;
покрытие, список отсутствующих наборов данных, метаданные источников,
диагностику, изменение параметров, приросты и лучших k можно пересобрать единым
способом.

4. Kernel Learning стал отдельной подсистемой фреймворка

fedot_ind.core.kernel_learning теперь выглядит не как набор экспериментальных
скриптов, а как публичная подсистема.

Основные части:

contracts.py: тип задачи, нормализация, исправление PSD, аппроксимация,
набор признаков, набор ядер, отчет о выборе.
estimators/: KernelEnsembleClassifier, KernelEnsembleRegressor,
KernelEnsembleForecaster.
generators/: базовые контракты, адаптеры репозитория, легкие генераторы,
спецификации операций, реестр.
kernels/: сборка матриц ядер, оценка сложности, аппроксимация Нистрема.
selection/: sparse MKL, целевые ядра, отчеты о важности.
integration/: определение задачи теплого старта и сборка начальных популяций.
experiments_api/: загружаемые артефакты первого и второго этапа, а также
классы запуска.
cache.py: детерминированный кеш ядер по отпечаткам массива и конфигурации.

Практический эффект для разработчика:

прямые пользователи могут импортировать оцениватели из
fedot_ind.core.kernel_learning;
пользователи бенчмарков получают те же оцениватели через адаптеры моделей
benchmark.industrial;
расширение генераторов теперь идет через реестр и спецификации операций, а не
через один большой файл adapters.py;
второй этап эволюционной оптимизации может использовать генераторы,
выбранные на первом этапе, как ленивые предположения теплого старта
PipelineBuilder.

5. Генераторы признаков разложены по тематическим модулям

После KL-401 старый крупный файл адаптеров генераторов разделен:

fedot_ind/core/kernel_learning/generators/
  base.py        общие контракты, нормализация, преобразование входов FEDOT
  repository.py  адаптеры репозитория и политики вычислительного бюджета
  lightweight.py identity, shapelet, random projection embedding
  specs.py       спецификации операций и параметры по умолчанию
  registry.py    реестр генераторов и разрешение спецификаций операций
  adapters.py    фасад совместимости

Публичные импорты при этом сохранены, но будущие изменения генераторов стало
намного проще читать и проверять.

Практический эффект для разработчика:

новая реализация генератора должна жить в тематическом модуле, который
отвечает за ее поведение;
adapters.py должен оставаться фасадом совместимости;
registry.py отвечает за публичные имена вроде wavelet_extractor,
embedding_extractor или tabular_extractor;
политики бюджета и запасные варианты выполнения изолированы в
repository.py.

6. Эксперименты Kernel Learning используют актуальные модели Industrial

Стандартный набор бенчмарков Kernel Learning теперь включает:

классификация:
- KernelEnsembleClassifier_score_baseline_summary;
- KernelEnsembleClassifier_adaptive_all_non_topological;
- KernelEnsembleClassifier_shapelet_motif_rbf;
- KernelEnsembleClassifier_embedding_nystrom;
регрессия:
- KernelEnsembleRegressor_score_linear_summary;
- KernelEnsembleRegressor_adaptive_rbf_summary;
- KernelEnsembleRegressor_shapelet_rbf;
- KernelEnsembleRegressor_embedding_nystrom;
прогнозирование:
- NaiveLastValue;
- LaggedRidgeForecaster;
- KernelEnsembleForecaster_identity_shapelet;
- KernelEnsembleForecaster_embedding_nystrom_okhs.

Настройки по умолчанию также задают:

наборы нетопологических генераторов;
метрики для конкретных задач;
шаблоны выходных папок;
поведение возобновляемых запусков;
поиск последнего первого этапа для двухэтапных запусков;
custom_dataset_policy для поведения на UCR и пользовательских данных.

7. Первый и второй этап Kernel Learning стали восстанавливаемыми процессами

Первый этап теперь записывает диагностику ядер и артефакты выбранных
генераторов. Их можно загрузить позже. Второй этап может либо запустить первый
этап, либо взять уже существующий запуск. Если второй этап не может собрать
начальную популяцию, он записывает структурированный статус пропуска или ошибки,
а не теряет состояние.

Ключевые файлы:

fedot_ind/core/kernel_learning/experiments_api/stage1.py
fedot_ind/core/kernel_learning/experiments_api/stage2.py
benchmark/experiments/kernel_learning/classification/run_ucr_two_stage.py
benchmark/industrial/evaluation/kernel_learning.py

Практический эффект для разработчика:

использовать KernelLearningStage1Runner для первого этапа на UCR;
использовать KernelLearningStage2Runner для эволюции FEDOT с теплым стартом;
не задавать stage1_run_id, если нужен автоматический поиск последнего
первого этапа;
использовать функции анализа, чтобы смотреть выбор генераторов до запуска
второго этапа.

8. Витрина результатов стала публичным окном состояния моделей

benchmark/results/showcase теперь отвечает на вопрос: «Как сейчас выглядят
модели Industrial по сравнению с SoTA и предыдущими версиями Industrial?»

Витрина индексирует:

UCR/UEA univariate classification;
multivariate classification;
TSER regression;
M4 monthly forecasting.

Она также формирует:

опись источников;
обзор бенчмарков;
лучшие результаты по наборам данных;
кандидатов на архивирование;
сводные пакеты по каждому направлению.

Практический эффект для разработчика:

использовать python -m benchmark.results.showcase для пересборки основной
витрины;
добавлять новые публичные сравнения через showcase_manifest.json;
не включать сырые исторические папки в публичные таблицы, если манифест явно
не называет их источниками.

9. Примеры переорганизованы по роли в воспроизводимости

Структура examples теперь основана на назначении:

examples/
  utils/                  утилиты текущего API и маленькие фикстуры
  tools_example/          сервисный слой для MCP и внешних агентов
  real_world_examples/    бенчмарковые и прикладные сценарии
  artifacts/              каталог артефактов, облачный пакет, локальная витрина

Удалены или выведены из основной структуры:

examples/benchmark_v2;
examples/outdated_examples;
старый сырой вид examples/data;
отдельная верхнеуровневая папка examples/rkhs_okhs;
старое название automl_example.

Практический эффект для разработчика:

начинать с python -m examples.utils.current_api;
использовать python -m examples.artifacts для пересборки описи артефактов и
локальной витрины;
использовать examples/tools_example для MCP или адаптеров внешних агентов;
использовать examples/real_world_examples для прикладных ноутбуков и
доменных сценариев.

10. Инструменты подготовлены для интеграции с внешними агентами

examples/tools_example больше не является набором тонких оберток над
примерами текущего API. Это сервисный слой Python со следующими частями:

contracts.py: ToolRequest, ToolResponse, ToolArtifact, ToolError;
registry.py: описания инструментов, JSON-схемы, маршрутизация вызовов;
services/data.py: список, загрузка и просмотр наборов данных;
services/training.py: конфигурации обучения и необязательное выполнение;
services/evolution.py: конфигурация двухэтапной оптимизации Kernel Learning;
services/pdl.py: конфигурация PDL-обучения;
services/anomaly.py: контекст и процесс детекции аномалий.

Все тяжелые инструменты по умолчанию работают в режиме предварительной проверки
и требуют execute=true для запуска обучения или оптимизации.

Практический эффект для разработчика:

внешний MCP-сервер может напрямую отразить описания из реестра в набор
инструментов;
каждый ответ имеет структуру и может включать сведения об артефактах;
политика локальных данных описана в README и tool_defaults.json.

Как работать с обновленным репозиторием

Добавить новое направление бенчмарка

Добавить исполняемую логику в benchmark/industrial/<domain>.
Добавить или переиспользовать BenchmarkSuiteConfig.
Положить таблицы моделей и настройки по умолчанию в JSON рядом с тематическим
пакетом.
Добавить тонкий запуск в benchmark/experiments/<family>/<task>.
Сохранять результаты через run_registered_suite или помощники реестра
манифестов.
Подключить агрегацию и визуализацию через общие функции benchmark.industrial.
Добавить источник в benchmark/results/showcase/showcase_manifest.json, если
результат должен стать публичным доказательством.
Добавить тесты на нормализацию конфигурации, проверку манифеста, агрегацию и
короткий короткий проверочный запуск.

Добавить новый генератор Kernel Learning

Писать общий контракт в generators/base.py только если он действительно
нужен нескольким генераторам.
Класть адаптеры репозитория или изменения политики бюджета в
generators/repository.py.
Класть маленькие только на numpy генераторы в generators/lightweight.py.
Описывать спецификации операций и параметры по умолчанию в generators/specs.py.
Регистрировать публичное имя генератора в generators/registry.py.
Держать generators/adapters.py только как фасад совместимости.
Добавлять тесты в tests/unit/core/kernel_learning/test_generators.py.

Добавить новый пример

Сначала выбрать роль:
- маленький воспроизводимый короткий проверочный пример: examples/utils/current_api;
- инструмент для внешнего агента: examples/tools_example;
- прикладной сценарий: examples/real_world_examples;
- сгенерированные отчетные артефакты: examples/artifacts.
Использовать типизированные конфигурации бенчмарков или актуальные
оцениватели Kernel Learning.
Держать каталогоподобные константы и настройки в JSON рядом с примером.
Не коммитить сырые локальные наборы данных и чекпойнты.
В README описывать локальные входы и ожидаемые выходы.
Если пример создает переиспользуемые графики или таблицы, регистрировать их
в каталоге артефактов.

Обновить результаты бенчмарков

Запустить или возобновить бенчмарк в benchmark/results/kernel_learning/....
Убедиться, что папки records и aggregate созданы.
Обновить манифест витрины, если источник должен попасть в публичное сравнение.
Выполнить:

python -m benchmark.results.showcase
python -m examples.artifacts

Проверить опись источников, покрытие, лучшие результаты по наборам данных и
кандидатов на архивирование.

v1docq · 2026-07-14T13:20:29Z

Закрыл финальный cleanup по замечаниям перед merge.

Что поправлено по инфраструктурным пунктам:

Старые benchmark.v2-доки переведены в миграционные страницы на benchmark.industrial; активные копируемые примеры from benchmark.v2 / python -m benchmark.v2 убраны.
kernel_learning_mvp_api.md больше не советует менять константы в начале скриптов: актуальный путь теперь через JSON defaults и типизированные конфигурации.
Внешние данные переведены с placeholder-ссылок Google Drive на публичный архив Яндекс.Диска: https://disk.yandex.ru/d/Ch_7K26rukpAWw; в manifest добавлены public_archive_subdir, owner, last_verified.
Для M4 forecasting в showcase явно указан режим industrial_internal_comparison до появления отдельного SoTA/Monash source.
В showcase/artifact manifests добавлены owner, last_refreshed, refresh_command, post-merge checklist и политика размера артефактов.

Что поправлено по комментариям Lopa10ko:

Удален старый файл плана из docs/kernel_clf_reg_docs: такие планы должны жить в issue/PR, а не в пользовательской документации.
Старый examples/benchmark_v2 уже выведен из активного контура; текущие manifests в examples/showcase держатся в JSON и проверяются тестами.
experiments_api перенесен из fedot_ind.core.kernel_learning в benchmark.industrial.experiments.kernel_learning; в fedot_ind.core.kernel_learning больше нет импортов benchmark.*.
По замечанию про SparseMKLSelector: добавлен AdaptiveKernelWeightSelector, старое имя оставлено только как совместимый alias; diagnostics теперь содержит selector_family.
InMemoryKernelCache используется в KernelEnsembleBase / KernelMatrixBuilder через KernelCacheKey и fingerprint данных.
Для stage2 добавлены явные skipped / failed summaries, reason/traceback и strict=True.
Тест experiments_api перенесен в benchmark test area, чтобы ownership соответствовал новому расположению пакета.

Что сознательно не стал превращать в большой refactor внутри этого cleanup:

Полную замену estimator constructors на dataclass/config object: это затрагивает sklearn-compatible get_params / set_params и лучше делать отдельной задачей.
Полную миграцию validation на marshmallow и backend-agnostic tensor typing для cupy/torch: это отдельный контракт ввода/валидации, не точечная правка перед merge.

Проверено локально:

py_compile по перенесенному Kernel Learning experiments package и обновленным imports.
PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 venv_3.9_new\Scripts\python.exe -m pytest -q tests\unit\benchmark\test_kernel_learning_experiments_api.py tests\unit\models\test_kernel_learning_experiment_scripts.py tests\unit\core\kernel_learning\test_selection.py tests\unit\examples\test_artifact_hub.py tests\unit\benchmark\test_results_showcase.py -> 35 passed.
Поиск старых путей/placeholders: нет совпадений для from benchmark.v2, python -m benchmark.v2, gdrive://<, <folder-id>, public_google_drive_url, fedot_ind.core.kernel_learning.experiments_api.
git diff --check без whitespace-ошибок; остались только стандартные предупреждения Git про LF -> CRLF в нескольких markdown/python-файлах.

v1docq · 2026-07-14T13:24:09Z

Что сделал в последних 2 коммитах

Обновил старую документацию про benchmark.v2 под benchmark.industrial.
Вставил ссылку на публичный архив Яндекс.Диска.
Явно пометил M4 forecasting как внутреннее сравнение Industrial до появления SoTA-источника.
Добавил ownership/freshness/refresh-команды и политику размера артефактов.
Удалил старый файл плана из docs/kernel_clf_reg_docs.
Перенёс experiments_api из fedot_ind.core.kernel_learning в benchmark.industrial.experiments.kernel_learning; в ядре больше нет импортов benchmark.*.
Добавил AdaptiveKernelWeightSelector, оставив SparseMKLSelector как совместимый alias.
Перенёс тесты experiments_api в benchmark-зону.

codecov · 2026-07-15T13:15:23Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.27%. Comparing base (f726f97) to head (e6568aa).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #225      +/-   ##
==========================================
+ Coverage   65.08%   70.27%   +5.18%     
==========================================
  Files         145      250     +105     
  Lines       13945    24398   +10453     
==========================================
+ Hits         9076    17145    +8069     
- Misses       4869     7253    +2384

Flag	Coverage Δ
unittests	`70.27% <ø> (+5.18%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Lopa10ko · 2026-07-16T13:08:33Z

+def parse_args() -> argparse.Namespace:
+    defaults = KernelLearningTwoStageUCRExperimentConfig()
+    parser = argparse.ArgumentParser(description="Run the two-stage UCR kernel-learning experiment.")
+    parser.add_argument(
+        "--run-stage-1",
+        action="store_true",
+        help="Run stage 1 before stage 2. By default stage 1 is loaded from saved artifacts.",
+    )
+    parser.add_argument(
+        "--stage1-run-id",
+        default=defaults.stage1_run_id,
+        help="Existing stage 1 run id to load when --run-stage-1 is not set. Defaults to latest discovery.",
+    )
+    parser.add_argument(
+        "--stage1-run-policy",
+        default=defaults.stage1_run_policy,
+        choices=("latest",),
+        help="How to resolve stage 1 when --stage1-run-id is omitted.",
+    )
+    parser.add_argument(
+        "--datasets",
+        nargs="*",
+        default=None,
+        help="UCR dataset names for stage 1. Pass no names after the flag to use all local datasets.",
+    )
+    parser.add_argument(
+        "--stage1-output-dir",
+        type=Path,
+        default=defaults.stage1_output_dir,
+        help="Directory containing or receiving stage 1 runs.",
+    )
+    parser.add_argument(
+        "--stage2-output-dir",
+        type=Path,
+        default=defaults.stage2_output_dir,
+        help="Directory receiving stage 2 optimization artifacts.",
+    )
+    parser.add_argument(
+        "--timeout-minutes",
+        type=int,
+        default=defaults.timeout_minutes,
+        help="FEDOT optimization timeout per dataset for stage 2.",
+    )
+    parser.add_argument(
+        "--pop-size",
+        type=int,
+        default=defaults.pop_size,
+        help="FEDOT population size for stage 2.",


nit-pick: здесь и везде в Fedot.Industrial - парсинг CLI вызовов через argparse обычно не очень хорошая идея в бенчмаркинге, достаточно устаревший подход, который хотелось бы в дальнейшем переписать на hydra yaml конфиги

при очередном запуске примера, бенча или просто тестирования хочется иметь какой-то артефакт этого запуска не только в логах, но и непосредственно рядом с файлом запуска

Lopa10ko · 2026-07-16T13:14:23Z

+if TYPE_CHECKING:
+    from benchmark.industrial.experiments.registry import BenchmarkRunBundle
+
+PROJECT_ROOT = Path(__file__).resolve().parents[3]


здесь и везде PROJECT_ROOT и другие пути до каких-либо директорий обычно должны прописываться единожды на уровне фреймворка (например, в fedot_ind/tools/serialisation/path_lib.py) и везде при необходимости можно прописывать from fedot_ind.tools.serialisation.path_lib import PROJECT_PATH или подобное, а не завязваться на конкретную файловую организацию в бенчмаркинг слое

если в дальнейшем бенчмаркинг будет изменяться, файлы будут переноситься и так далее, возможны проблемы с путями

Lopa10ko · 2026-07-16T13:16:31Z

+def print_benchmark_run_bundle(bundle: "BenchmarkRunBundle") -> None:
+    print(f"Run ID: {bundle.result.run_id}")
+    print(f"Output dir: {bundle.result.config.artifact_spec.output_dir}")
+    print(f"Run dir: {bundle.run_dir}")
+    print(f"Registry entry: {bundle.registry_entry_path}")


здесь и везде вместо print в консоль лучше логировать и сохранять лог запуска

Lopa10ko · 2026-07-16T13:22:06Z

 from .stage1 import DEFAULT_STAGE_METRICS

-DEFAULT_STAGE2_OUTPUT_DIR = Path("benchmark") / "results" / "v2_kernel_learning" / "ucr_two_stage_optim_140526"
+DEFAULT_STAGE2_OUTPUT_DIR = Path("benchmark") / "results" / "kernel_learning" / "ucr_two_stage_optim_140526"


привязываться к конкретной дате бенчмаркинга ucr_two_stage_optim_140526 - code smell

Lopa10ko · 2026-07-16T13:24:08Z

@@ -136,6 +131,8 @@ def run_registered_manifest_path(path: str | Path) -> BenchmarkRunBundle:


 def run_registered_manifest(payload: dict[str, Any]) -> BenchmarkRunBundle:
+    from benchmark.industrial.experiments.manifests import render_resolved_manifest, run_manifest
+
    resolved_payload = render_resolved_manifest(payload)
    result = run_manifest(payload)
    return persist_run_bundle(
@@ -148,10 +145,16 @@ def run_registered_manifest(payload: dict[str, Any]) -> BenchmarkRunBundle:

 def run_registered_suite(config: BenchmarkSuiteConfig) -> BenchmarkRunBundle:
    if config.task_type is TaskType.FORECASTING:
+        from benchmark.industrial.api import run_forecasting_benchmark_suite
+
        result = run_forecasting_benchmark_suite(config)
    elif config.task_type is TaskType.TS_CLASSIFICATION:
+        from benchmark.industrial.api import run_tsc_benchmark_suite
+
        result = run_tsc_benchmark_suite(config)
    elif config.task_type is TaskType.TS_REGRESSION:
+        from benchmark.industrial.api import run_tser_benchmark_suite
+
        result = run_tser_benchmark_suite(config)
    else:  # pragma: no cover
        raise ValueError(f'Unsupported task type: {config.task_type}')
@@ -175,6 +178,8 @@ def run_registered_preset(
        include_optional_external: bool = False,
        models=None,
 ) -> BenchmarkRunBundle:
+    from benchmark.industrial.experiments.presets import run_local_benchmark_preset
+
    result = run_local_benchmark_preset(


зачем здесь используются nested imports внутри методов?

Lopa10ko · 2026-07-16T13:50:48Z

+class Either:
+    def __init__(self, value: Any, is_right: bool):
+        self.value = value
+        self._is_right = is_right
+
+    def is_left(self) -> bool:
+        return not self._is_right
+
+    def is_right(self) -> bool:
+        return self._is_right
+
+    def either(self, left: Callable[[Any], Any], right: Callable[[Any], Any]) -> Any:
+        return right(self.value) if self._is_right else left(self.value)
+
+
+def Left(value: Any) -> Either:
+    return Either(value, is_right=False)
+
+
+def Right(value: Any) -> Either:
+    return Either(value, is_right=True)


зачем каждый раз вводить either? можно пользоваться pymonad

Lopa10ko · 2026-07-16T13:54:47Z

+@lru_cache(maxsize=1)
+def load_real_world_defaults(path: str | Path = DEFAULTS_PATH) -> dict[str, Any]:
+    defaults_path = Path(path)
+    payload = json.loads(defaults_path.read_text(encoding="utf-8"))
+    if not isinstance(payload, dict):
+        raise ValueError(f"Real-world example defaults root must be a mapping: {defaults_path}")
+    version = str(payload.get("version", ""))
+    if version != DEFAULTS_VERSION:
+        raise ValueError(f"Unsupported real-world example defaults version: {version}")
+    return payload


везде встречаются похожие методы load_*_defaults, можно единожды реализовать в утилитах бенчмаринга или примеров и переиспользовать везде, они отличаются только названием метода в сигнатуре и в ошибке ValueError

применимо и к остальным методам, которые по какой-то причине не переиспользуются, а пишутся заново под конкретный скрипт

Lopa10ko · 2026-07-16T13:57:13Z

+from .current_api import main
+
+if __name__ == "__main__":
+    raise SystemExit(main())


зачем?

Lopa10ko · 2026-07-16T14:17:02Z

проверить, используется ли это вообще? если нет, то удалить или все же применить

если я верно понимаю, cwrapped нужен для реализации метода tessellate, который используется в fedot_ind.tools.explain.pcd.numpy2stl, который используется в fedot_ind/core/operation/transformation/representation/topological/topological_extractor._generate_pcd, но закомментирован (вместо этого используется какая-то эвристика)

Fedot.Industrial/fedot_ind/core/operation/transformation/representation/topological/topological_extractor.py

Lines 80 to 100 in 0466e0f

def _generate_pcd(self, ts_data, persistence_params):

window_size_range = list(range(1, 35, 5))

stride_range = list(range(1, 15, 3))

list(product(window_size_range, stride_range))

# for params in pcd_params:

# data_transformer = TopologicalTransformation(stride=params[1], persistence_params=persistence_params,

# window_length=round(ts_data.shape[0] * 0.01 * params[0]))

# point_cloud = data_transformer.time_series_to_point_cloud(input_data=ts_data, use_gtda=True)

# # VR_mesh = self._generate_vr_mesh(point_cloud)

# for scale in range(1, 15, 3):

# numpy2stl(point_cloud,

# f"./stl_scale_{scale}_ws_{params[0]}_stride_{params[1]}.stl",

# max_width=300.,

# max_depth=200.,

# max_height=300.,

# scale=scale,

# min_thickness_percent=0.5,

# solid=False)

# pcd = o3d.geometry.PointCloud()

# pcd.points = o3d.utility.Vector3dVector(point_cloud)

# o3d.io.write_point_cloud(f"./pcd_ws_{params[0]}_stride_{params[1]}.ply", pcd)

Lopa10ko · 2026-07-16T14:19:14Z

зачем добавлен lock?
убрать poetry.lock, добавить в .gitignore

v1docq · 2026-07-17T11:20:44Z

Что вошло в cleanup commit:

убрал из git examples/artifacts/cloud_bundle, examples/artifacts/showcase, poetry.lock,fedot_ind/tools/explain/cwrapped.c;
удалил benchmark.industrial.legacy и старые legacy-входы из public API;
перевел artifact hub на политику “генерируем локально, публикуем во внешнее хранилище, не коммитим”;
поправил benchmark paths через общий PROJECT_PATH, убрал date-specific stage2 default;
заменил print на логируемый run_info.log;
вынес общий JSON defaults loader в examples/utils/config_io.py;
заменил локальный Either на pymonad.either;
добавил явное назначение examples.tools_example.main.

v1docq and others added 6 commits May 14, 2026 16:42

Start with kernel methods and contracts for TSER UCR bench

55687ce

First iter of 2-stage kernel algo in Fedot

1168649

Little init files

9073030

Fixing in 2 stage kernel algo. Refactor unit test. Create plan for ne…

037a5ca

…xt PR

Automated autopep8 fixes

7ebbfd2

Implement hardened kernel learning contracts, sparse MKL, generators,…

9a1db76

… forecasting estimator, and benchmark diagnostics

v1docq requested a review from Lopa10ko June 2, 2026 14:22

Implement experiment layer for Kernel learning on UCR M4 TSER bench

e54a351

Lopa10ko requested changes Jun 2, 2026

View reviewed changes

v1docq added 15 commits June 4, 2026 13:04

Kernel learning experiment after debug. Starting point for KL issues

d4436c1

Finish issue KL-101. Refactor benchmark module. Remove legacy benchma…

9d76853

…rk modules and group experiments

Finish issue KL-102. Unify kernel learning benchmark runner configs

c1695db

KL-103. Continue refactor example module

3165f3b

KL-103. Create cloud bundle and reorg files in example module

3123775

KL-103. Continue

2d53036

KL-104. Update dashboard

f59ac21

KL-105. bench contracts

1d75826

KL-106 Add unified benchmark result aggregation module

fcc8e67

KL-106 Add minor artifacts

e169d9b

KL-201

65dda1e

KL cleanup: track examples artifact bundle

bae0c76

KL-202

e069310

KL-301 Add kernel cache and stage2 diagnostics

2618fff

KL-302 Improve kernel learning runner defaults

2df24f5

KL-401 Split generator adapters into domain modules

e32b998

v1docq added 2 commits July 14, 2026 16:21

Documentation updates

420cd9b

Documentation updates

3d23c14

v1docq added 7 commits July 14, 2026 16:46

Resolve PR #225 merge conflicts with main

0e90144

Move KL docs to wiki and keep Codex files local

fd3379f

Fix CI formatting and benchmark public exports

ff10fed

Fix autopep8 checkout token

4bc66e5

Fix unit CI fixtures and portable benchmark tests

045f525

Fix residual unit CI regressions

6d15a10

Fix hankelisation unit reference contract

bf87a6d

Lopa10ko requested changes Jul 16, 2026

View reviewed changes

v1docq and others added 2 commits July 17, 2026 13:57

Cleanup benchmark review artifacts

91ae2d2

Automated autopep8 fixes

c93dcbb

Lopa10ko approved these changes Jul 17, 2026

View reviewed changes

v1docq added 4 commits July 17, 2026 14:41

Fix CI runtime setuptools dependency

784f3f7

Install setuptools in CI poetry environments

45c974c

Pin setuptools range for pkg_resources compatibility

b0a73dd

Make benchmark analysis contracts external-data aware

e6568aa

v1docq merged commit 829ea6d into main Jul 17, 2026
3 checks passed

	def _generate_pcd(self, ts_data, persistence_params):
	window_size_range = list(range(1, 35, 5))
	stride_range = list(range(1, 15, 3))
	list(product(window_size_range, stride_range))
	# for params in pcd_params:
	# data_transformer = TopologicalTransformation(stride=params[1], persistence_params=persistence_params,
	# window_length=round(ts_data.shape[0] * 0.01 * params[0]))
	# point_cloud = data_transformer.time_series_to_point_cloud(input_data=ts_data, use_gtda=True)
	# # VR_mesh = self._generate_vr_mesh(point_cloud)
	# for scale in range(1, 15, 3):
	# numpy2stl(point_cloud,
	# f"./stl_scale_{scale}_ws_{params[0]}_stride_{params[1]}.stl",
	# max_width=300.,
	# max_depth=200.,
	# max_height=300.,
	# scale=scale,
	# min_thickness_percent=0.5,
	# solid=False)
	# pcd = o3d.geometry.PointCloud()
	# pcd.points = o3d.utility.Vector3dVector(point_cloud)
	# o3d.io.write_point_cloud(f"./pcd_ws_{params[0]}_stride_{params[1]}.ply", pcd)

Uh oh!

Conversation

v1docq commented Jun 2, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

v1docq commented Jul 14, 2026

Обзор KL-изменений перед вливанием в main

Резюме

Что было проверено

Цепочка связанных issues:

Было и стало

Что изменилось в работе фреймворка

1. Запуск бенчмарков стал типизированным и привязанным к реестру

2. Стало ясно, где живет код бенчмарков

3. Результаты запусков стали полноценными входными данными анализа

4. Kernel Learning стал отдельной подсистемой фреймворка

5. Генераторы признаков разложены по тематическим модулям

6. Эксперименты Kernel Learning используют актуальные модели Industrial

7. Первый и второй этап Kernel Learning стали восстанавливаемыми процессами

8. Витрина результатов стала публичным окном состояния моделей

9. Примеры переорганизованы по роли в воспроизводимости

10. Инструменты подготовлены для интеграции с внешними агентами

Как работать с обновленным репозиторием

Добавить новое направление бенчмарка

Добавить новый генератор Kernel Learning

Добавить новый пример

Обновить результаты бенчмарков

Uh oh!

v1docq commented Jul 14, 2026

Uh oh!

v1docq commented Jul 14, 2026

Uh oh!

codecov Bot commented Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

v1docq commented Jul 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Обзор KL-изменений перед вливанием в `main`

codecov Bot commented Jul 15, 2026 •

edited

Loading